Internet Engineering Task Force (IETF) H. Singh 


Request for Comments: 6204 W. Beebee 
Category: Informational Cisco Systems, Inc. 
ISSN: 2070-1721 C. Donley 
CableLabs 

B. Stark 

AT&T 


O. Troan, Ed. 
Cisco Systems, Inc. 
April 2011 


Basic Requirements for IPv6é Customer Edge Routers 


Abstract 


This document specifies requirements for an IPv6 Customer Edge (CE) 
router. Specifically, the current version of this document focuses 
on the basic provisioning of an IPv6 CE router and the provisioning 
of IPv6é hosts attached to it. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6204. 


Copyright Notice 


Copyright (c) 2011 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
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include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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1. Introduction 


This document defines basic IPv6 features for a residential or small- 
office router, referred to as an IPv6 CE router. Typically, these 
routers also support IPv4. 


Mixed environments of dual-stack hosts and IPv6-only hosts (behind 
the CE router) can be more complex if the IPv6-only devices are using 
a translator to access IPv4 servers [RFC6144]. Support for such 
mixed environments is not in scope of this document. 


This document specifies how an IPv6 CE router automatically 
provisions its WAN interface, acquires address space for provisioning 
of its LAN interfaces, and fetches other configuration information 
from the service provider network. Automatic provisioning of more 
complex topology than a single router with multiple LAN interfaces is 
out of scope for this document. 


See [RFC4779] for a discussion of options available for deploying 
IPv6 in service provider access networks. 
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1.1. Requirements Language 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 


2. Terminology 


End-User Network 


IPv6 Customer Edge Router 


IPv6 Host 


LAN Interface 


Service Provider 


WAN Interface 
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one or more links attached to the IPv6 CE 
router that connect IPv6 hosts. 


a node intended for home or small-office 
use that forwards IPv6 packets not 
explicitly addressed to itself. The IPv6 
CE router connects the end-user network to 
a service provider network. 


any device implementing an IPv6 stack 
receiving IPv6 connectivity through the 
IPv6 CE router. 


an IPv6 CE router's attachment to a link in 
the end-user network. Examples are 
Ethernets (simple or bridged), 802.11 
wireless, or other LAN technologies. An 
IPv6 CE router may have one or more 
network-layer LAN interfaces. 


an entity that provides access to the 
Internet. In this document, a service 
provider specifically offers Internet 
access using IPv6, and may also offer IPv4 
Internet access. The service provider can 
provide such access over a variety of 
different transport methods such as DSL, 
cable, wireless, and others. 


an IPv6 CE router’s attachment to a link 
used to provide connectivity to the service 
provider network; example link technologies 
include Ethernets (simple or bridged), PPP 
links, Frame Relay, or ATM networks, as 
well as Internet-layer (or higher-layer) 
"tunnels", such as tunnels over IPv4 or 
IPv6 itself. 
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3. Architecture 
3.1. Current IPv4 End-User Network Architecture 


An end-user network will likely support both IPv4 and IPvé. It is 
not expected that an end-user will change their existing network 
topology with the introduction of IPv6é. There are some differences 
in how IPv6 works and is provisioned; these differences have 
implications for the network architecture. A typical IPv4 end-user 
network consists of a "plug and play" router with NAT functionality 
and a single link behind it, connected to the service provider 
network. 


A typical IPv4 NAT deployment by default blocks all incoming 
connections. Opening of ports is typically allowed using a Universal 
Plug and Play Internet Gateway Device (UPnP IGD) [UPnP-IGD] or some 
other firewall control protocol. 


Another consequence of using private address space in the end-user 
network is that it provides stable addressing; i.e., it never changes 
even when you change service providers, and the addresses are always 
there even when the WAN interface is down or the customer edge router 
has not yet been provisioned. 


Rewriting addresses on the edge of the network also allows for some 
rudimentary multihoming, even though using NATs for multihoming does 
not preserve connections during a fail-over event [RFC4864]. 


Many existing routers support dynamic routing, and advanced end-users 
can build arbitrary, complex networks using manual configuration of 
address prefixes combined with a dynamic routing protocol. 


3.2. IPv6 End-User Network Architecture 
The end-user network architecture for IPv6 should provide equivalent 
or better capabilities and functionality than the current IPv4 


architecture. 


The end-user network is a stub network. Figure 1 illustrates the 
model topology for the end-user network. 
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Figure 1: An Example of a Typical End-User Network 
This architecture describes the: 
o Basic capabilities of an IPv6 CE router 


o Provisioning of the WAN interface connecting to the service 
provider 


o Provisioning of the LAN interfaces 


For IPv6 multicast traffic, the IPv6 CE router may act as a Multicast 
Listener Discovery (MLD) proxy [RFC4605] and may support a dynamic 
multicast routing protocol. 


The IPv6 CE router may be manually configured in an arbitrary 
topology with a dynamic routing protocol. Automatic provisioning and 
configuration are described for a single IPv6 CE router only. 
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1. Local Communication 


Link-local IPv6 addresses are used by hosts communicating on a single 
link. Unique Local IPv6 Unicast Addresses (ULAs) [RFC4193] are used 
by hosts communicating within the end-user network across multiple 
links, but without requiring the application to use a globally 
routable address. The IPv6 CE router defaults to acting as the 
demarcation point between two networks by providing a ULA boundary, a 
multicast zone boundary, and ingress and egress traffic filters. 


A dual-stack host is multihomed to IPv4 and IPv6 networks. The IPv4 
and IPv6 topologies may not be congruent, and different addresses may 
have different reachability, e.g., ULAs. A host stack has to be able 
to quickly fail over and try a different source address and 
destination address pair if communication fails, as outlined in 
[HAPPY-EYEBALLS]. 


At the time of this writing, several host implementations do not 
handle the case where they have an IPv6 address configured and no 
IPv6 connectivity, either because the address itself has a limited 
topological reachability (e.g., ULA) or because the IPv6 CE router is 
not connected to the IPv6 network on its WAN interface. To support 
host implementations that do not handle multihoming in a multi-prefix 
environment [MULTIHOMING-WITHOUT-NAT], the IPv6 CE router should not, 
as detailed in the requirements below, advertise itself as a default 
router on the LAN interface(s) when it does not have IPv6 
connectivity on the WAN interface or when it is not provisioned with 
IPv6 addresses. For local IPv6 communication, the mechanisms 
specified in [RFC4191] are used. 


ULA addressing is useful where the IPv6 CE router has multiple LAN 
interfaces with hosts that need to communicate with each other. If 
the IPv6 CE router has only a single LAN interface (IPv6 link), then 
link-local addressing can be used instead. 


In the event that more than one IPv6 CE router is present on the LAN, 
then coexistence with IPv4 requires all of them to conform to these 
recommendations, especially requirements ULA-5 and L-4 below. 


Requirements 
General Requirements 


The IPv6 CE router is responsible for implementing IPv6 routing; that 
is, the IPv6 CE router must look up the IPv6 destination address in 
its routing table to decide to which interface it should send the 
packet. 
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In this role, the IPv6é CE router is responsible for ensuring that 
traffic using its ULA addressing does not go out the WAN interface, 
and does not originate from the WAN interface. 


G-1: An IPv6 CE router is an IPv6 node according to the IPv6 Node 
Requirements [RFC4294] specification. 


G-2: The IPv6 CE router MUST implement ICMP according to [RFC4443]. 
In particular, point-to-point links MUST be handled as 
described in Section 3.1 of [RFC4443]. 


G-3: The IPv6 CE router MUST NOT forward any IPv6 traffic between 
its LAN interface(s) and its WAN interface until the router has 
successfully completed the IPv6 address acquisition process. 


G-4: By default, an IPv6 CE router that has no default router(s) on 
its WAN interface MUST NOT advertise itself as an IPv6é default 
router on its LAN interfaces. That is, the "Router Lifetime" 
field is set to zero in all Router Advertisement messages it 
originates [RFC4861]. 


G-5: By default, if the IPv6 CE router is an advertising router and 
loses its IPv6 default router(s) on the WAN interface, it MUST 
explicitly invalidate itself as an IPv6 default router on each 
of its advertising interfaces by immediately transmitting one 
or more Router Advertisement messages with the "Router 
Lifetime" field set to zero [RFC4861]. 


4.2. WAN-Side Configuration 


The IPv6 CE router will need to support connectivity to one or more 
access network architectures. This document describes an IPv6 CE 
router that is not specific to any particular architecture or service 
provider and that supports all commonly used architectures. 


IPv6 Neighbor Discovery and DHCPv6 protocols operate over any type of 
IPv6-supported link layer, and there is no need for a link-layer- 
specific configuration protocol for IPv6é network-layer configuration 
options as in, e.g., PPP IP Control Protocol (IPCP) for IPv4. This 
section makes the assumption that the same mechanism will work for 
any link layer, be it Ethernet, the Data Over Cable Service Interface 
Specification (DOCSIS), PPP, or others. 


Singh, et al. Informational [Page 7] 


RFC 6204 


IPv6 CE Router Requirements April 2011 


WAN-side requirements: 


W-1: 


When the router is attached to the WAN interface link, it MUST 
act as an IPv6 host for the purposes of stateless [RFC4862] or 
stateful [RFC3315] interface address assignment. 


The IPv6 CE router MUST generate a link-local address and 
finish Duplicate Address Detection according to [RFC4862] prior 
to sending any Router Solicitations on the interface. The 
source address used in the subsequent Router Solicitation MUST 
be the link-local address on the WAN interface. 


Absent other routing information, the IPv6 CE router MUST use 
Router Discovery as specified in [RFC4861] to discover a 
default router(s) and install default route(s) in its routing 
table with the discovered router’s address as the next hop. 


The router MUST act as a requesting router for the purposes of 
DHCPv6 prefix delegation ([RFC3633]). 


DHCPv6 address assignment (IA_NA) and DHCPv6é prefix delegation 
(IA_PD) SHOULD be done as a single DHCPv6 session. 


The IPv6 CE router MUST use a persistent DHCP Unique Identifier 
(DUID) for DHCPv6 messages. The DUID MUST NOT change between 
network interface resets or IPv6 CE router reboots. 


Link-layer requirements: 


WLL-1: 


WLL-2: 


WLL-3: 


If the WAN interface supports Ethernet encapsulation, then 
the IPv6 CE router MUST support IPv6 over Ethernet [RFC2464]. 


If the WAN interface supports PPP encapsulation, the IPv6 CE 
router MUST support IPv6 over PPP [RFC5072]. 


If the WAN interface supports PPP encapsulation, in a dual- 
stack environment with IPCP and IPV6CP running over one PPP 
logical channel, the Network Control Protocols (NCPs) MUST be 
treated as independent of each other and start and terminate 
independently. 
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Address assignment requirements: 


WAA-1: 


WAA-2: 


WAA-3: 


WAA-4: 


WAA-5: 


WAA-6: 


WAA-7: 


WAA-8: 


WAA-9: 


The IPv6 CE router MUST support Stateless Address 
Autoconfiguration (SLAAC) [RFC4862]. 


The IPv6 CE router MUST follow the recommendations in Section 
4 of [RFC5942], and in particular the handling of the L flag 
in the Router Advertisement Prefix Information option. 


The IPv6 CE router MUST support DHCPv6 [RFC3315] client 
behavior. 


The IPv6 CE router MUST be able to support the following 
DHCPv6 options: IA_NA, Reconfigure Accept [RFC3315], and 
DNS_SERVERS [RFC3646]. 


The IPv6 CE router SHOULD support the DHCPv6 Simple Network 
Time Protocol (SNTP) option [RFC4075] and the Information 
Refresh Time option [RFC4242]. 


If the IPv6 CE router receives a Router Advertisement message 
(described in [RFC4861]) with the M flag set to 1, the IPv6 
CE router MUST do DHCPv6 address assignment (request an IA_NA 
option). 


If the IPv6 CE router is unable to assign address(es) through 
SLAAC, it MAY do DHCPv6 address assignment (request an IA_NA 
option) even if the M flag is set to 0. 


If the IPv6 CE router does not acquire global IPv6 
address(es) from either SLAAC or DHCPv6, then it MUST create 
global IPv6 address(es) from its delegated prefix(es) and 
configure those on one of its internal virtual network 
interfaces. 


As a router, the IPv6 CE router MUST follow the weak host 
(Weak ES) model [RFC1122]. When originating packets from an 
interface, it will use a source address from another one of 
its interfaces if the outgoing interface does not have an 
address of suitable scope. 
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Prefix delegation requirements: 


WPD-1: 


WPD-2: 


WPD-3: 


WPD-4: 


WPD-5: 


WPD-6: 


WPD-7: 


WPD-8: 


The IPv6 CE router MUST support DHCPv6 prefix delegation 
requesting router behavior as specified in [RFC3633] (IA_PD 
option). 


The IPv6 CE router MAY indicate as a hint to the delegating 
router the size of the prefix it requires. If so, it MUST 
ask for a prefix large enough to assign one /64 for each of 
its interfaces, rounded up to the nearest nibble, and MUST be 
configurable to ask for more. 


The IPv6 CE router MUST be prepared to accept a delegated 
prefix size different from what is given in the hint. If the 
delegated prefix is too small to address all of its 
interfaces, the IPv6 CE router SHOULD log a system management 
error. 


The IPv6 CE router MUST always initiate DHCPv6 prefix 
delegation, regardless of the M and O flags in a received 
Router Advertisement message. 


If the IPv6 CE router initiates DHCPv6 before receiving a 
Router Advertisement, it MUST also request an IA_NA option in 
DHCPv6. 


If the delegated prefix(es) are aggregate route(s) of 
multiple, more-specific routes, the IPv6 CE router MUST 
discard packets that match the aggregate route(s), but not 
any of the more-specific routes. In other words, the next 
hop for the aggregate route(s) should be the null 
destination. This is necessary to prevent forwarding loops 
when some addresses covered by the aggregate are not 
reachable [RFC4632]. 


(a) The IPv6 CE router SHOULD send an ICMPv6 Destination 
Unreachable message in accordance with Section 3.1 of 
[RFC4443] back to the source of the packet, if the 
packet is to be dropped due to this rule. 


If the IPv6 CE router requests both an IA_NA and an IA_PD 
option in DHCPv6, it MUST accept an IA_PD option in DHCPv6 
Advertise/Reply messages, even if the message does not 
contain any addresses. 


By default, an IPv6 CE router MUST NOT initiate any dynamic 
routing protocol on its WAN interface. 
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4.3. LAN-Side Configuration 


The IPv6 CE router distributes configuration information obtained 
during WAN interface provisioning to IPv6 hosts and assists IPv6 
hosts in obtaining IPv6é addresses. It also supports connectivity of 
these devices in the absence of any working WAN interface. 


An IPv6 CE router is expected to support an IPv6 end-user network and 
IPv6 hosts that exhibit the following characteristics: 


1. Link-local addresses may be insufficient for allowing IPv6 
applications to communicate with each other in the end-user 
network. The IPv6 CE router will need to enable this 
communication by providing globally scoped unicast addresses or 
ULAs [RFC4193], whether or not WAN connectivity exists. 


2. IPv6 hosts should be capable of using SLAAC and may be capable of 
using DHCPv6 for acquiring their addresses. 


3. IPv6 hosts may use DHCPv6 for other configuration information, 
such as the DNS_SERVERS option for acquiring DNS information. 


Unless otherwise specified, the following requirements apply to the 
IPv6 CE router’s LAN interfaces only. 


ULA requirements: 


ULA-1: The IPv6 CE router SHOULD be capable of generating a ULA 
prefix [RFC4193]. 


ULA-2: An IPv6 CE router with a ULA prefix MUST maintain this prefix 
consistently across reboots. 


ULA-3: The value of the ULA prefix SHOULD be user-configurable. 


ULA-4: By default, the IPv6 CE router MUST act as a site border 
router according to Section 4.3 of [RFC4193] and filter 
packets with local IPv6 source or destination addresses 
accordingly. 


ULA-5: An IPv6 CE router MUST NOT advertise itself as a default 


router with a Router Lifetime greater than zero whenever all 
of its configured and delegated prefixes are ULA prefixes. 
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LAN requirements: 


L-1: 


Singh, 


et 


The IPv6 CE router MUST support router behavior according to 
Neighbor Discovery for IPv6 [RFC4861]. 


The IPv6 CE router MUST assign a separate /64 from its 
delegated prefix(es) (and ULA prefix if configured to provide 


ULA addressing) for each of its LAN interfaces. 


An IPv6 CE router MUST advertise itself as a router for the 


delegated prefix(es) (and ULA prefix if configured to provide 
ULA addressing) using the "Route Information Option" specified 
in Section 2.3 of [RFC4191]. This advertisement is 


independent of having or not having IPv6 connectivity on the 
WAN interface. 


An IPv6 CE router MUST NOT advertise itself as a default 
router with a Router Lifetime [RFC4861] greater than zero if 
it has no prefixes configured or delegated to it. 


The IPv6 CE router MUST make each LAN interface an advertising 
interface according to [RFC4861]. 


In Router Advertisement messages, the Prefix Information 
option’s A and L flags MUST be set to 1 by default. 


The A and L flags’ settings SHOULD be user-configurable. 


The IPv6 CE router MUST support a DHCPv6 server capable of 
IPv6 address assignment according to [RFC3315] OR a stateless 
DHCPv6 server according to [RFC3736] on its LAN interfaces. 


Unless the IPv6 CE router is configured to support the DHCPv6 
TA_NA option, it SHOULD set the M flag to 0 and the O flag to 
1 in its Router Advertisement messages [RFC4861]. 


The IPv6 CE router MUST support providing DNS information in 
the DHCPv6 DNS_SERVERS and DOMAIN_LIST options [RFC3646]. 


The IPv6 CE router SHOULD support providing DNS information in 
the Router Advertisement Recursive DNS Server (RDNSS) and DNS 
Search List (DNSSL) options as specified in [RFC6106]. 


The IPv6 CE router SHOULD make available a subset of DHCPv6 
options (as listed in Section 5.3 of [RFC3736]) received from 
the DHCPv6 client on its WAN interface to its LAN-side DHCPv6 
server. 


al. Informational [Page 12] 


RFC 6204 IPv6 CE Router Requirements April 2011 


L-13: If the delegated prefix changes, i.e., the current prefix is 
replaced with a new prefix without any overlapping time 
period, then the IPv6 CE router MUST immediately advertise the 
old prefix with a Preferred Lifetime of zero and a Valid 
Lifetime of the lower of the current Valid Lifetime and 2 
hours (which must be decremented in real time) in a Router 
Advertisement message as described in Section 5.5.3, (e) of 
[RFC4862]. 


L-14: The IPv6 CE router MUST send an ICMP Destination Unreachable 
message, code 5 (Source address failed ingress/egress policy) 
for packets forwarded to it that use an address from a prefix 
that has been deprecated. 


4.4. Security Considerations 


It is considered a best practice to filter obviously malicious 


traffic (e.g., spoofed packets, "Martian" addresses, etc.). Thus, 
the IPv6 CE router ought to support basic stateless egress and 
ingress filters. The CE router is also expected to offer mechanisms 


to filter traffic entering the customer network; however, the method 
by which vendors implement configurable packet filtering is beyond 
the scope of this document. 


Security requirements: 


S-1: The IPv6 CE router SHOULD support [RFC6092]. In particular, 
the IPv6 CE router SHOULD support functionality sufficient for 
implementing the set of recommendations in [RFC6092], 

Section 4. This document takes no position on whether such 
functionality is enabled by default or mechanisms by which 
users would configure it. 


S-2: The IPv6 CE router MUST support ingress filtering in accordance 
with BCP 38 [RFC2827]. 
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